Codecov Report

Merging #1410 into master will increase coverage by 0.03%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #1410      +/-   ##
==========================================
+ Coverage   87.27%   87.31%   +0.03%     
==========================================
  Files          25       25              
  Lines        5383     5398      +15     
==========================================
+ Hits         4698     4713      +15     
  Misses        685      685

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 50f9c6c...6054482. Read the comment docs.

This feels like a "feature" that we might want to think about backporting to 1.x

I wouldn't oppose that, but I am curious why you think we should backport this.

Because otherwise packages that want to support this have to drop the LTS version of julia. Maybe it isn't a big deal.

I like this. To fully obsolete #1349, this would also need to document 0.7-*.

A concern that should be considered is if we want to support pre-release versions then 1.2.3-4.5.6 is both a valid version range and a pre-release of 1.2.3 with pre-release tuple (4, 5, 6). See https://github.com/npm/node-semver#prerelease-tags.

We could just disambiguate that as a version range, which seems like the more common case, although then there isn’t any way to write the pre-release version, whereas if we interpreted this as the pre-release version the version range can still be written as 1.2.3 - 4.5.6 since that is clearly not a single version number.

Maybe enforce having a space on the sides of the hypen for now?

Would it be nuts to use a different character than - which already means something in the actual standardized semver syntax? We could write 1.2.3:4.5.6 for version ranges. The : character has no meaning in single-version syntax. That's a bit of an unfortunate mismatch with the registry range syntax, but 🤷‍♂

Would it be nuts to use a different character than - which already means something in the actual standardized semver syntax? We could write 1.2.3:4.5.6 for version ranges. The : character has no meaning in single-version syntax. That's a bit of an unfortunate mismatch with the registry range syntax, but 🤷‍♂

1.2.3:4.5.6 seems kind of hard to read. So many dots! How about using the word to? Then you’d have 1.2.3 to 4.5.6.

At that point I'd rather have 1.2.3 - 4.5.6 with required spaces.

→?

Another option may be --. In LaTeX it's compiled to an en-dash which is used to represent a range of values: https://en.wikipedia.org/wiki/Dash#Ranges_of_values

I wouldn't oppose that, but I am curious why you think we should backport this.

I think with the current push to encourage dependency version limits (upper bounds now required for automatic merging on General), this feature would be very very helpful, and I'd be very glad if it were backported to v1.0!

I just ran into a situation where this package resolution failed, because I upgraded "ElasticArrays" to v1.0 and updated another package to require it - but another dependency that I wanted required "ElasticArrays" v0.2. I can work around that by just setting "ElasticArray <= 2.0" on my other package - but what if I need a lower bound as well?

I have a distinct feeling that without the ability to specify deps version ranges, will run into (extremely frustrating) situations in which package resolution fails more and more often, as package authors put tighter bounds on dependency versions.

this feature would be very very helpful, and I'd be very glad if it were backported to v1.0!

As a general rule, features aren't backported. Pkg is a bit special though, and I've been toying around with the idea of making releases of 1.0 with an updated version of Pkg.

@fredrikekre reminded me that it's already possible to specify a comma-separated list of versions -somehow I missed that or forgot about it, sorry! So since there's a decent workaround, I'll have take back my earlier statement about this needing a backport to 1.0.

I completely forgot about this pull request. What was the latest decision? Enforce a space on either side of the hyphen? I.e. 1.2.3 - 4.5.6 is allowed, but 1.2.3-4.5.6 is not allowed?

Alright, I have updated the PR with all of the review comments.

I am enforcing the rule that there must be whitespace on both sides of the hyphen. That way, there is no confusion/ambiguity with prerelease notation.

I think this is ready to merge. cc: @StefanKarpinski @KristofferC @fredrikekre

Bump @StefanKarpinski @KristofferC @fredrikekre.

Where did we land on this PR? Do we want to merge it? Or do we want to close it and push users towards using caret and tilde notation instead?

Bump. Any update on merging this?

FWIW node seems to use the same "space padded hyphen" notation for ranges: https://docs.npmjs.com/misc/semver

Also, the tests seem pretty comprehensive.